The field of the invention is distributed object technology; more specifically, the invention relates to managing the location, activation and invocation of objects in a distributed object environment including object request brokers.
The Common Object Request Broker Architecture (CORBA) of the Object Management Group (OMG) is a set of specifications defining a language-independent distributed object architecture including Object Request Brokers (ORBs) for transparently managing the details of making requests and receiving responses of remote objects. Details on CORBA, including the complete specification, may be had from the Object Management Group, 492 Old Connecticut Path, Framingham, MA 01701 (www.omg.org).
In order for CORBA object implementations to interact with CORBA ORBs, object adapters (OAs) are used. Object adapters provide a ""standardized interface for object implementations, but themselves communicate with, ORBs via vendor-specific interfaces. Object adapters are responsible for demultiplexing requests from remote clients and dispatching the requests to appropriate servant object implementations, activating and deactivating objects and generating object references among other functions.
ORB clients in the CORBA environment use Interoperable Object References (IORs) generated by servers to request operations on target objects. The CORBA specification describes a structural framework for CORBA IORs, comprising a set of profiles. Profiles may include a portion called the object key that may be included in client request messages to identify the target object of the request. The object key format is not specified by CORBA and may be opaque (not parsed or interpreted) to applications developers and to client side ORBs. Because they are used to locate and invoke objects in a distributed computing environment, implemented CORBA IOR profiles have conventionally included location information such as the computer host name or port number as well as an object identifier for locating and invoking the target object.
Shortcoming in earlier CORBA object adapter definitions led to the introduction of the Portable Object Adapter (POA) in CORBA 2.2. The Portable Object Adapter is described in Chapter 9 of the CORBA version 2.2 specification, and in a series of articles by Douglas C. Schmidt of Washington University and Steve Vinoski of IONA Technologies, Inc. appearing in SIGS C++ Report magazine beginning in October 1997, and in Advanced CORBA Programming with C++ by Michi Henning and Steve Vinoski (Addison Wesley Longman, 1999, ISBN 0-201-37927-9).
POAs may be either transient or persistent. Persistent objects in CORBA ((including objects implemented using persistent POAs) are objects whose lifetimes are independent of the lifetimes of any processes in which they are activated. Transient objects are objects whose lifetimes are constrained by the lifetimes of the processes in which they are created. In the context of a POA (and as used in this application), xe2x80x9cpersistencexe2x80x9d refers principally to the a persistent object""s persistence across multiple process activations. It does not necessarily imply persistent state (as, for example, objects in an object database have persistent state) and persistent POAs need not have persistent state.
Conventional CORBA systems use IORs that are not well suited to use with persistent CORBA objects that outlive the processes in which they are activated, or objects that may require changes to services provided or used to access them during their lifetimes, because such changes have typically required changes to the IORs for those objects. Clients holding such an IOR will find the reference invalid, or inefficient to use because additional services are required for invocations with the IOR. Conversely, the existence of such IORs limits the administrative flexibility of the system because trade-offs must be made between desired administrative actions and the risks posed by compromising existing IORs. Additional administrative burdens are imposed by the substantial configuration and address allocation requirements of conventional CORBA systems.
The present invention overcomes these and other limitations of conventional CORBA systems.
Object migration is facilitated by a location service. References to objects are exported that contain the information needed to communicate with the locator rather than directly with the server in which they are implemented. The location service is configured to always listen for requests at the same set of addresses, which are advertised in these references. Servers then can listen for requests at addresses that are dynamically assigned each time a server program is executed, eliminating the need to administratively configure fixed addresses for each server, and allowing the server to migrate between hosts. When a server is executed, it sends its current address to the locator. When clients attempt to communicate with the object, they use the information in the exported reference to establish communications with the locator. The locator then returns the current server address to the client (referred to as location forwarding), enabling the client to communicate directly with the server.
In one aspect of the present invention, the location service is preferably provided by exchanging object references between the server and the locator. The server constructs a prototype object reference, referred to as a prototype direct IOR, that includes the information needed by a client to communicate directly with that server. The locator similarly constructs a prototype object reference, referred to as a prototype:indirect IOR, with the information needed to communicate directly with a location agent.
These prototype references are exchanged between the server and the locator. The server exports the objects it implements using object references constructed by inserting those objects identities into the prototype reference received from the locator. When the client sends a request to the locator, the locator extracts the target object""s identity from the request, and inserts that identity into the prototype reference obtained from the server, and returns the resulting reference to the client.
The server and the location service may use different sets of plug-in transports and other services for communicating with client ORBs. For example, client ORBs communicating with the server using direct IORs may use plug-in transports or other services which need not be available to the location service. Similarly, client ORBs communicating with the location service may use plug-in transports or other services which need not be available to the server, and may use different security or quality of service Information.
In another aspect of the invention, scalability to large numbers of objects is preferably enhanced by maintaining location information for groups of objects, referred to as xe2x80x9cendpointsxe2x80x9d, rather than for individual objects. An object""s identity is split into two portions: an endpoint identity and an object identity relative to that endpoint. In a preferred implementation, the locator maintains current location information for each endpoint by exchanging prototype references with the server for each endpoint. When the locator receives a request for a target object, it maps the endpoint identity portion of the object""s identity to the information needed to generate the object reference to return to the client, and inserts the object identity that was receive from the client.
In another aspect of the invention, CORBA POA instances are treated as endpoints, and the POA is a unit of object migration. The fully qualified POA name is used as part of the endpoint identifier. Policy objects associated with the POA instance affect what transports and ORB services it supports, and the information needed by a client to use these transports and ORB services is then advertised in the xe2x80x9cprototypexe2x80x9d object reference generated for that POA and exchanged with the locator.
In one embodiment, the present invention comprises a prototype object reference for use in a distributed object computing environment comprising a specified object reference portion and an unspecified object reference portion wherein the prototype object reference is transformed into a valid object reference by insertion of specification information into the unspecified object reference portion.
The prototype object reference need not be parsed in connection with insertion of the specification information.
Another aspect of the invention comprises a method of providing an object reference, comprising the steps of a first entity generating a prototype object reference, and providing the prototype object reference to another entity. In a preferred embodiment, the prototype object reference comprises information for communicating with the first entity. In a further aspect of the present invention, the second entity generates a second prototype object reference, and provides the second prototype object reference to the first entity. In a preferred embodiment, the second prototype object reference comprises information for communicating with the second entity.
In a further aspect of the present invention, a first entity generates a direct prototype object reference having a specified object reference portion specific to a collection of objects, the direct prototype object reference is provided to a second entity, and object identifier information sufficient to identify an object of the collection of objects is inserted into the direct prototype object reference.
In a preferred embodiment, the invention comprises a location information repository, comprising an identifier of a collection of one or more objects, information of a prototype object reference associated with the identifier, the prototype object reference being configured to receive information of an object identifier specific to at least one of the objects.
Another aspect of the invention comprises a system for facilitating object migration in a distributed object computing environment, comprising an endpoint identity to location identity mapping; a location identity to process name mapping; wherein the endpoint identity to location identity mapping is independent of the location identity to process name mapping. In a preferred embodiment, the system further comprises a process name to process activator mapping. The system may include selection of a process activator from a plurality of process activators corresponding to a process name is determined by a criterion. The criterion may be determined at run-time. The system also permits a plurality of location identities to be mapped to a single process name. The system may be further configured to comprise a process name to process mapping, and in such a system a single process name may be mapped to a plurality of processes. Selection of a process from a plurality of processes corresponding to a process name may determined by a criterion, and the criterion may be determined at run-time.
In another aspect, the invention comprises establishing policies for endpoints of an object request broker system, storing policy information associated with a non-terminal of an endpoint naming hierarchy; applying the policy information to all descendants of the non-terminal.